Here it is.

When you stage changes, there is a nearly invisible textfield for entering a commit comment. Perhaps you will see it right away. It took me a while. After entering a comment, you can commit.

XCode 14.3.1. Everything is up to date. Oddly, disabling Settings->General->Show Live Issues brings back the error messages. Re-enabling them makes them go away again. Weird, but thanks.

Didn't know there was more. See below.

Thread 1 Queue : com.apple.main-thread (serial) #0 0x0000000187103a6c in computeZ(CALayer*, CALayer*, CA::Transaction*, CA::Vec2 const&, double) () #1 0x00000001871015c4 in -[CALayer hitTest:] () #2 0x0000000187103998 in hitTestSublayers(X::List<CALayer*>, CA::Vec2 const&, CALayerArray) () #3 0x0000000187101574 in -[CALayer hitTest:] () #4 0x0000000187103998 in hitTestSublayers(X::List<CALayer*>, CA::Vec2 const&, CALayerArray) () #5 0x0000000187101574 in -[CALayer hitTest:] () #6 0x0000000187103998 in hitTestSublayers(X::List<CALayer*>, CA::Vec2 const&, CALayerArray) () #7 0x0000000187101574 in -[CALayer hitTest:] () #8 0x0000000101013790 in VNode.touchesBegan(:with:) at /Users/steve/Desktop/DragginMath/DragginMath/DragginMath/View/VNode.swift:256 #9 0x0000000101013b34 in @objc VNode.touchesBegan(:with:) () #10 0x000000018587fed8 in _UIGestureEnvironmentUpdate () #11 0x000000018343182c in CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION () #12 0x0000000183402a64 in __CFRunLoopDoObservers () #13 0x00000001833fdfec in __CFRunLoopRun () #14 0x0000000183411240 in CFRunLoopRunSpecific () #15 0x00000001a3d27988 in GSEventRunModal () #16 0x0000000185c1141c in -[UIApplication _run] () #17 0x00000001859aab88 in UIApplicationMain () #18 0x0000000100fe39a0 in main at /Users/steve/Desktop/DragginMath/DragginMath/DragginMath/AppDelegate.swift:12 #19 0x00000001016dc3d0 in start () Thread 2#0 0x00000001bcfe3014 in __workq_kernreturn () Thread 4#0 0x00000001bcfe3014 in __workq_kernreturn () com.apple.uikit.eventfetch-thread (6)#0 0x00000001bcfe2aac in mach_msg_trap () #1 0x00000001bcfe307c in mach_msg () #2 0x00000001833f9d78 in __CFRunLoopServiceMachPort () #3 0x00000001833fe080 in __CFRunLoopRun () #4 0x0000000183411240 in CFRunLoopRunSpecific () #5 0x0000000184b1eefc in -[NSRunLoop(NSRunLoop) runMode:beforeDate:] () #6 0x0000000184b5e010 in -[NSRunLoop(NSRunLoop) runUntilDate:] () #7 0x0000000185b9086c in -[UIEventFetcher threadMain] () #8 0x0000000184b6bc0c in NSThread__start () #9 0x00000001dd679348 in _pthread_start ()

That is the entire stack trace for the thread that crashed the app.

Let's try this again. The stuff with DispatchQueue was added as a result of a suggestion elsewhere. The behavior is the same, with or without the DispatchQueue wrapper. internal func animateBack(_ aoTouchSession:TouchSession,reconnect ayReconnect:Bool = true) { let ksCGPoint = aoTouchSession.hsCGPointLayer projectStrokeColor(LOperand.gkoCGColorStroke) DispatchQueue.main.async(execute:DispatchWorkItem( qos:.unspecified, flags:[], block:{ UIView.animate( withDuration:10, animations:{self.frame.origin = ksCGPoint}, completion:{ay in if ay && ayReconnect {self.drawGlyphAndConnector()}} ) } )) }

My iOS app builds an interactive picture as a tree of CALayers. The user can touch and drag these layers around on the screen. In some circumstances, these motions "do something". In other circumstances, they don't "do something", and the layer that was dragged moves back to where it came from in a smooth animation. The animation works: I can see the smooth motion. What doesn't work is to make it move at different speeds by changing the duration parameter. Regardless of what number I put there, it always animates at the same speed. If you want to see it, look for "DragginMath" on the AppStore, or on YouTube. Those videos don't show the "moving back" behavior, but you'll get the idea.

Reported as FB9125801. Thanks again.

"|√(a↑2+b↑2)|" Thanks. I think it would be ideal if I could use TextEdit to select a string and mark it as non-breaking.

I'm working in code, not IB, so I'm not sure everything in the video applies. I create my text with the link in TextEdit, then import it into NSAttributedString. And it works... once. Nevertheless, I just changed my code to make the UITextView selectable, as suggested in the video. And I implemented the method with the complicated name. Upon testing: no difference in behavior. BTW the method with the complicated name is never invoked, nor do I see why it would be. Even without that method, the link is taken once. OK, I just saw your edit. I have now made my VC implement UITextViewDelegate and set itself as the delegate. And I haven't set up the other method you mention. What is the code inside that method? Looking further into textView(UITextView,shouldInteractWith:URL,in:NSRange,interaction:UITextItemInteraction)->Bool, it looks like the video code is doing things it doesn't need to do. All that method needs to do is return true. At this point, the method is invoked in my code, but only once. The doc for that method says something in Discussion about only being invoked once, but its example is not clear. So I am back to thinking this is some invisible undocumented state issue within UITextView.

And here is the problem: In iOS 9.3.5, subclass CALayer, then instantiate. Your app will crash. The subclass doesn't even need to have any instance variables or methods. Just define a subclass, then instantiate. Instant death. Looking a little farther into it, the subclass initializer immediately deallocates the instance. I asked Apple about this. They said they won't do anything about it.

I don't have an SSCCE for this. Plain vanilla init invocation, as far as I can tell. I know the deinit runs because I overrode it and have a breakpoint in it.

That fixed it. Thanks!

I eventually blundered into the answer to this. I had to configure the textfield to not autocapitalize.